让知识复利：用 LLM 建一个会生长的个人 wiki

让 LLM 维护一个持续增长的个人 wiki，而不是每次查询都从零开始。

Karpathy 最近公开了一种 llm-wiki 的理念：让 LLM 维护一个持久的个人知识库，而不是每次查询都从原始文档重新检索。他在 Obsidian vault 中划分了三个层次——raw 存放原始资料，wiki 是 LLM 编译产出的内容，schema 则是 CLAUDE.md 等配置文件。我研究之后发现，这套理念可以很自然地嫁接到我现有的笔记结构上——只需要新增一个 3.wiki/ 层，交给 LLM 来维护。现在系统已经跑起来了，这篇文章记录一下我的思路和实践。

我之前的笔记困境

我一直在用 Obsidian 管理笔记，积累了不少内容——AUTOSAR 教程、Racket 和 Lisp 的学习笔记、编程语言理论的文章、嵌入式系统的资料。但这些材料散落在收件箱里，质量参差不齐，彼此之间缺乏关联。每次想查什么东西，要么靠记忆在文件夹里翻找，要么直接问 LLM 从头解释一遍。知识是积累了不少，但知识之间是孤立的，不成体系。

也试过 RAG 方案——把文档丢进去，检索的时候让 LLM 从中找答案。但 RAG 有个根本问题：它没有记忆。每次查询都是一次性的，LLM 从原始文档中检索片段、生成回答，然后一切归零。一百次查询之后，系统并不比第一次查询时更聪明。知识没有被编译、没有沉淀、没有生长。

llm-wiki 的核心洞察

Karpathy 的 llm-wiki 给出了另一种思路：不要每次都从原始文档出发，而是让 LLM 维护一个持久的、持续增长的 wiki。他的原话很精辟：

Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

这个类比非常准确。源代码是对现实世界的抽象，wiki 是对原始资料的编译；程序员维护代码库，LLM 维护 wiki。每次有新的源文件进来，LLM 不是简单地存储它，而是消化它——提取概念、建立关联、更新现有页面，就像程序员理解了新需求后会重构代码一样。

这样做的好处是复利效应：知识库会随着使用越来越完善。每一次 ingest 都让 wiki 更丰富，每一次 query 如果产生了有价值的回答，也可以沉淀回 wiki。这不是一个工具，而是一个活的系统。

后来我和朋友聊起这个方案时，有人提到它和 RAG 其实不是对立的——RAG 解决的是检索问题，llm-wiki 解决的是知识沉淀问题，两者可以互补。不过对我个人来说，llm-wiki 的范式已经够用了，我还没有遇到需要回退到 RAG 的场景。

我如何将 llm-wiki 融入现有结构

我没有从头设计一套新的目录结构，而是在现有的 Obsidian vault 基础上做了扩展。Karpathy 的三层架构（Raw、Wiki、Schema）很简洁，但我需要一个收件箱来缓冲未审阅的内容。最初我设计过一个包含私人文件区的五层结构，但后来发现私人文件完全可以放在 vault 之外，不需要占一个专门的层级。去掉之后，目录更简洁了。最终的四层结构是：

0.asset/       → 静态资源（图片、模板）
1.inbox/       → 待审阅文章（剪藏、AI 生成、私人笔记）
2.raw/         → 精选源文件（人工确认质量后移入，不可变）
3.wiki/        → LLM 维护的 wiki 页面

每一层都有明确的权限边界：

• 1.inbox/ 是缓冲区，质量未确认的材料先放在这里，只有我确认质量合格后才手动移入 Raw 层。LLM 不主动动 inbox 的文件。账号密码等敏感信息只能留在 inbox 中，不进入 Raw 层。
• 2.raw/ 是不可变的源文件层。LLM 只读，不修改、不删除、不移动。这是 wiki 的"源代码"。
• 3.wiki/ 完全交给 LLM。它负责创建、更新、维护所有页面和交叉引用。我在这里只读。

Schema 层就是 vault 根目录下的 CLAUDE.md，它定义了整个系统的运作规则——目录结构、页面类型、操作流程、格式约定。LLM 每次工作时都会读取这个文件，确保行为一致。

三种页面类型

我设计了三种 wiki 页面模板，放在 0.asset/template/ 下：

Wiki-Topic（主题页）：围绕一个知识领域组织的页面，比如"嵌入式系统"、"车载网络"、"函数式编程"。每个主题页包含概述、按子主题分节的核心概念、关键源文件链接、相关 wiki 页面的交叉引用，以及一个"待深入"区域标记还需要研究的问题。

Wiki-Entity（实体页）：关于具体人物、项目或组织的页面。比如"王垠"这个实体页会收录他的核心观点、相关文章索引，以及与其他 wiki 页面的关联。

Wiki-Concept（概念页）：跨主题的通用概念，比如"S-表达式"、"Continuation"、"类型系统"。这些概念可能在多个主题中出现，独立成页可以避免重复，也便于建立跨领域的关联。

三种页面类型的区分让 wiki 有了结构感——不是一堆平铺的文章，而是一个有层次的知识图谱。

三个核心操作

整个系统的运作围绕三个操作展开：

Ingest（摄入）

当我把一篇新文章移入 2.raw/ 后，告诉 LLM 有新内容。它会读取源文件，与我讨论关键要点，然后创建或更新相关 wiki 页面。一次 ingest 可能同时影响五到十个页面——更新已有主题页的相关章节、创建新的概念页、补充实体页的文章索引、更新所有受影响页面的 frontmatter。最后它会更新 index.md 并在 log.md 中追加一条操作记录。

这个过程就像给一棵树浇水——水不是简单倒在地上，而是被根系吸收，输送到每一片需要的叶子。

Query（查询）

当我提问时，LLM 先读 index.md 定位相关页面，然后读取具体的 wiki 页面。如果需要更多细节，再去读 Raw 层中的源文件。回答时会附上 wikilink 引用，方便我在 Obsidian 中跳转。如果回答本身有价值（比如一个对比分析或深度综述），LLM 会建议我存为新的 wiki 页面。

Lint（巡检）

定期检查 wiki 的健康状况：页面间是否有矛盾、是否有孤立页面、是否有高频概念缺少独立 concept 页、frontmatter 是否一致、"待深入"部分是否有可以推进的。这就像代码仓库的 CI——持续保证质量。

目前的状态

系统已经跑起来了。2.raw/ 层有近 300 篇精选源文件，3.wiki/ 层有近 20 个 wiki 页面，覆盖了 AUTOSAR、Racket、Lisp、函数式编程、嵌入式系统、车载网络、编程语言理论、软件工程哲学等主题。CLAUDE.md 作为 schema 文件完整定义了系统的运作规则。

每次 ingest 都能感受到 wiki 在生长——新的源文件不只是被存下来，而是被编织进已有的知识网络中。这和以前把文章丢进收件箱然后再也不看的感觉完全不同。

还有一个值得一提的细节：inbox 层按内容来源做了子目录划分——clippings/（Web Clipper 剪藏）、ai-generated/（AI 生成的笔记）、tech/（技术文章）、life/（生活记录）等。这个分类不是 wiki 的一部分，只是帮助我自己在审阅时快速定位不同来源的内容。

一些思考

这个系统最让我满意的是分工明确：我负责筛选和决策（什么值得读、移入 Raw 层），LLM 负责编译和维护（消化内容、更新 wiki、保持一致性）。我不需要亲自整理笔记，但知识体系在持续完善。

Inbox 层的缓冲作用也很重要。我的收件箱里有很多 AI 生成的内容，质量参差不齐。如果让 LLM 直接处理 inbox，低质量内容会污染 wiki。所以我把审阅权留给自己——只有我确认有价值的内容才会进入 Raw 层，LLM 才会处理。这也是为什么我把私人文件从 vault 中移出去了——vault 只存知识，不存生活。结构更纯粹，LLM 的职责也更清晰。

还有一个意外的好处：因为 wiki 页面有明确的模板和规范，LLM 的输出质量变得稳定可预测。不像随意聊天那样时而精彩时而平庸，wiki 的结构化格式约束了 LLM 的输出，也让整个知识库保持了一致的风格。

Karpathy 说 llm-wiki 的核心是让知识compound——像复利一样增长。我现在的体验确实如此。每一篇新文章不是在空地上盖房子，而是在已有的城市里修新路、建新楼。知识之间有了连接，wiki 也就有了生命。